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Abstract 



The invention concerns a method for transmitting data, called objects, via at least a communication 
network, between a server and at least a client terminal, at least a cache memory, designed to store at least 
some of said objects transmitted by the server, being associated, in said network, with at least one of said 
client terminals. The invention is characterized in that it consists in managing, upstream of said client 
terminals, at least a list of objects present in said cache memory associated with at least one of said client 
terminals, so as to limit exchange of data concerning the content of said cache memory between said client 
terminal and said server. 
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PROCEDE DE TRANSMISSION D'OBJETS ENTRE UN SERVEUR ET UN TERMINAL CLIENT METTANT EN 
OEUVRE UNE GESTION DE CACHE, SYSTEME DE TRANSMISSION, SERVEUR ET TERMINAL 
CORRESPONDANTS. 

fy L'invention conceme un proc6d6 de transmission de 
nn6es, appetees objets, via au moins un r§seau de com- 
munication, entre un serveur et au moins un terminal client, 

au moins une m6moire cache, destin6e a stocker au moins ^ , 

certains desdits objets transmis par ledit serveur, 6tant as- 
soctee, au sein dudit r6seau, a I'un au moins desdits termi- 
naux clients. 

Selon l'invention, on gSre, en arnont desdits terminaux 
clients, au moins une liste d'objets presents dans ladite m6- 
moire cache assoctee a I'un desdits terminaux clients, afin 
de limiter les ^changes d'informations relatives au contenu 
de ladite mSmoire cache entre ledit terminal client et ledit 
serveur. 
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Procede de transmission d'objets entre un serveur et un terminal 
client mettant en oeuvre une gestion de cache, systeme de transmission, 
serveur et terminal correspondants. 

Le domaine de Pinvention est celui de la transmission de donnees au 
5 travers de reseaux de communication. Plus pr6cisement, Tinvention conceme la 
transmission de donnees destinees a etre visualisees de maniere interactive, et la 
gestion de caches correspondante. 

Les developpements extraordinaires des reseaux de communication 
permettent aujourdliui aux utilisateurs de visualiser des modeles de type images, 
10 textures, modeles gtometriques ou scenes 3D par exemple, de maniere interactive, 
et en temps reel. Classiquement, les utilisateurs se connectent, via un terminal 
adapte, a un serveur dfetant, qui centralise dans une base de donnees l'ensemble 
des informations necessaires a Kitilisateur pour une telle visualisation (on notera 
que, bien que Ton emploie ici le terme "visualisation", de telles infoimalions 
15 peuvent incline des donnees de toutes natures, et notamment de type son, de type 
paginees, etc.). 

Les utilisateurs peuvent ainsi acceder a de nouvelles applications, du type 
leur permettant par exemple de se deplacer dans un environnement virtuel 3D, 
comme un musee virtuel, un relief de terrain, ou encore un concert de musique 
20 classique. Dans le cadre de ces applications, le serveur envoie done au client les 
informations necessaires a la reconstruction de la scene globale, ainsi que les 
informations relatives aux difierents objets de la scene, qui entrent dans le champ 
de vision (ou dans le champ d'ecoute) de l'utilisateur, en fonction de sa position 
dans la sc£ne. 

25 Uinvention s'applique notamment, mais non exclusivement, a une telle 

transmission, ainsi qu'au stockage, en vue par exemple d*une utilisation future, 
^informations de tout type, accessibles par un utilisateur via un serveur de 
donn6es. 

Bi effet, afin de pOTiettre une visualisation en temps reel (telle que decrite 
30 ci-dessus) dHine scene ou d'une video par exemple, on associe g^neralement au 
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terminal de l'utilisateur un cache, dans lequel sont stockees toutes les informations 
necessaires a la reproduction de la scene, en temps reel, par le terminal. 

Un tel cache memorise classiquement des donnees dites "pass6es", c'est-&- 
dire des donnees qui ont deja 6t6 utilisees par le terminal pour reproduire une 
5 sc£ne ou une image, mais qui pourront peut-etre etre reutilisees ulterieurement, en 
fonction des besoins de l'utilisateur. D stocke egalement les donnees dites 
"presentes", c'est-a-dire les donnees en cours d'utilisation par le terminal, et enfin 
eventuellement des donn6es dites "futures", qui pourront etre necessaires au 
terminal dans un avenir proche, et qui resultent d'une anticipation du serveur sur 
10 les besoins de l'utilisateur. 

Comme on le comprendra aisement, le volume ^informations que le 
serveur doit transmettre d'une part, et qui doivent etre gerees dans le cache d'autre 
part, est considerable, notamment dans le cas ou l'utilisateur souhaite visualiser 
des donnees de tres grande taille, comme par exemple des scenes 
1 5 tridimensionnelles tr^s vastes. 

Pour resoudre les problemes afferents au volume eleve de donnees 
echangees entre le client et le serveur coirespondant, on a envisage d'introduire 
plusieurs methodes de traitement, et notamment : 

un algorithme de remplacement, qui permet, lorsque le taux de remplissage 
20 du cache est elev£, de choisir les donnees stockeds a siq>primer pour 

liberer de l'espace memoire ; 

une methode de transmission, qui regit le choix, par le serveur, des 
donndes a envoyer au client, ainsi que le mode de transmission de ces 
donnees. 

25 On connait k ce jour deux methodes principals de transmission, 

permettant de creer un dialogue entre le client et le serveur, et indiquant k ce 
dernier les informations a traiBmettre au client 

La premiere methode de transmission connue est notamment decrite dans 
le document "Multi- Resolution Model Transmission in Distributed Virtual 
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Environments" (en fran^ais "Transmission de modeles multi-resolution en 
environnements virtuek distribues") par J. H. P. Chim et al., VRST98, p. 25-34. 

Selon cette premiere m6thode, 1'envoi, par le serveur, de donnees que le 
client souhaite visualiser se decompose en quatre etapes successives : 
5 - au cours d'une premiere etape, le terminal du client transmet au serveur 

une information relative a la position de l'utilisateur dans la scene a 

visualiser; 

sur reception de cette information de position, le serveur calcule tous les 
objets n&essaires a l'utilisateur, et, au cours d'une deuxieme etape; lui 

10 transmet la liste des couples <0, Lo> d'objets necessaires, oiO est une 

reference de l'objet, et Lo un niveau de detail correspondant ; 
le terminal client choisit alors, parmi cette liste, et en fonction du contenu 
de son cache, les couples correspondant aux objets qu'il souhaite recevoir, 
et transmet au serveur le resultat de son choix, au cours d'une troisieme 

15 etape ; 

au cours d'une quatrieme etape, le serveur transfere les objets demandes 
par le terminal du client 

Un inconvenient de cette technique de l'art anterieur est qu'a chaque fois 
que la position de l'utilisateur dans la scene est modifi6e, et done a chaque fois 
20 que le serveur doit envoyer un ou plusieurs nouveaux objets a l'utilisateur, deux 
echanges complets de donnees, sous forme d'allers-retours, sont necessaires entre 
le serveur et le terminal client, avant que le ou les objet(s) necessaire(s) ne 
devienne(nt) accessible(s) a l'utilisateur, via sa memoire cache. 

Une telle technique rfest done pas adaptee a la transmission de donnees au 
25 travers des reseaux de communication qui pr&entent une grande latence : en effet, 
pour de tels reseaux, cette technique ne peimet pas une visuahsation en temps reel 
des donnees transmises par le serveur. 

Une deuxieme methode de transmission connue est decrite dans 1'article 
"On Caching and Prefetching of Virtual Objects in Distributed Virtual 
30 Environments" (en fi^ais "Gestion de cache et preextraction d'objets virutels en 
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environnements virtuels distribues") par X H. P. Chim et al., Proceedings of the 
sixth ACM international conference on Multimedia, 1998, pages 171-180. 

Selon cette seconde methode, qui est plus particulierement adaptee a la 
transmission d'objets codes progressivement, le terminal client transmet au 
5 serveur, a chacun de ses mouvements dans la sc&ne visualisee, une information 
sur sa position, ainsi qu'une information relative au contenu de son cache, sous la 
forme de couples <0, Lo>. A nouveau, 0 represente une reference de l'objet 
contenu dans le cache du client, et Lo indique au serveur le niveau de detail 
associe a cet objet 

10 Le serveur calcule alors, en fonction de la position de l'utilisateur dans la 

scene, Tensemble des objets visuellement pertinents, verifie si ces objets sont ou 
non deja presents dans le cache de Mlisateur, et transmet au client l'ensemble 
des objets manquants. 

Selon cette methode, un seul aller-retour entre le client et le serveur est 

15 done necessaire pour transferer au client les donnees necessaires a la visualisation 
de la scene. 

Cependant, un inconvenient de cette technique de Tart anterieur est qu f elle 
est tres consommatrice en termes de ressources reseau, et notamment en termes de 
bande passante. En effet, a chaque mouvement de l'utilisateur dans la scene, le 

20 terminal client transfere au serveur Kntegralite des informations relatives au 
contenu de son cache (e'est-ardire Tensemble des couples <0, U> correspondant 
aux objets contenus dans son cache). 

Dans le cas de la visualisation de scenes tits vastes, la quantite 
^informations transmises du terminal client au serveur est done tres elevee, ce qui 

25 est particulierement penalisant dans le cadre des reseaux de communication a bas 
debit 

^invention a notamment pour objectif de pallier ces inconvenients de Part 
anterieur. 

Plus precisement, un objectif de Pinvention est de foumir une technique de 
30 transmission, d'un serveur vers un terminal client, d r informations necessaires a 
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une visualisation en temps reel de donnfes de grande taille, en minimisant les 
transferts entre le serveur et le terminal client 

Un autre objectif de l'invention est de mettre en ceuvre une telle technique 
de transmission de donnees qui soit simple et peu couteuse a mettre en ceuvre. 
5 L'invention a encore pour objectif de foumir une telle technique de 

transmission de donnees a travers un reseau de communication, qui soit adaptee a 
tout type de reseau, et notamment aussi bien aux reseaux presentant une grande 
latence qu'aux reseaux h bas debit 

L'invention a egalement pour objectif de mettre en ceuvre une telle 

10 technique de transmission de donntes qui permette d'eviter les redondances de 
transmission de donnees du serveur au terminal client 

Encore un objectif de l'invention est de proposer une telle technique de 
transmission de donnees qui permette de supprimer, ou h tout le moins de reduire, 
les requetes de donn6es emises par le terminal client a destination du serveur. 

15 Ces objectifs, ainsi que d'autres qui apparaitront par la suite, sont atteints a 

1'aide d'un procede de transmission de donnees, appelees objets, via au moins in 
reseau de communication, entre un serveur et au moins un terminal client, au 
moins une memoire cache, destinee a stocker au moins certains desdits objets 
transmis par ledit serveur, etant associee, au sein dudit reseau, a l*un au moins 

20 desdits teiminaux clients. 

Selon l'invention, on gere, en amont desdits terminaux clients, au moins 
une liste d'objets presents dans ladite memoire cache assoctee a l*un desdits 
tenninaux clients, afin de limiter les ^changes ^informations relatives au contenu 
de ladite memoire cache entre ledit terminal client et ledit serveur. 

25 Ainsi, Tinvention repose sur une approche tout a fait nouvelle et inventive 

de la gestion des memoires caches. Notamment, l'invention repose sur Tidee 
innovante et avantageuse de maintenir, en amont d'un terminal client, une liste, 
accessible au serveur de donnees, representative du contenu d'un cache associe au 
client. Cette solution permet done au serveur de connaitre a tout moment le 

30 contenu du cache du client, sans que ce contenu ne soit duplique au niveau du 
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serveur. ^invention propose done une solution qui, bien que peu couteuse en 
termes de ressources, et notamment de memoire, pour le serveur, permet de 
reduire considerablement le volume ^informations echangees entre le serveur et 
le client, lore de la visualisation d*une scene ou dto ensemble d'objets par le 
5 client Une telle solution est partiailierement avantageuse pour les terminaux 
clients de capacite r6duites, ou pour les reseaux de communication de 
performances limitees. 

Avantageusement, on memorise, au sein de ladite lists, un identifiant de 
chacun desdits objets et, pour Fun au moins desdits objets, une information de 
10 restitution dudit objet 

Le serveur peut done avoir acces, non seulement a la liste des objets 
contenus dans le cache du client, mais egalement au niveau de restitution auquel 
ils peuvent etre reproduits par le client 

Preferentiellement, pour Fun au moins desdits objets, ladite information de 
1 5 restitution est relative h un niveau de raffinement dudit objet 

Le serveur peut done savoir si le terminal client peut reproduire Fobjet 
sous forme grossiere ou detaillee par exemple. 

De maniere preferentielle, pour chacun desdits objets stockes dans ladite 
memoire cache, ladite liste comprend un couple <0, Lo> comprenant ledit 
20 identifiant 0 dudit objet et ladite information de restitution Lo dudit objet 

Selon une caracteristique avantageuse de Finvention, pour chacun desdits 
terminaux clients, on associe a ladite liste au moins une information relative audit 
terminal cliert et/ou a un utilisateur dudit terminal client, appelee information de 
visualisation, de fa$on a former un contexte. 
25 Pour chacun des clients connectes au serveur, ce dernier gere done un 

contexte comprenant une liste representative de Tetat du cache qui bur est associe, 
ainsi que des informations de visualisation. De telles informations peuvent 
notamment etre representatives de la capacite du terminal du client, ou de sa 
rapidite de traitement 
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Preferentiellement, ladite information de visualisation appartient au groupe 
comprenant : 

une infonnation de position dudit utilisateur ; 

une direction d'observation dudit utilisateur ; 
5 - les parametres de selection desdits objets. 

De tels parametres de selection comprennent par exemple un seuil de 
selection des objets, ainsi qu\m angle de vue de Tobservateur. Dans le cas de la 
visualisation dtoe scene 3D par le terminal du client, l'information de position 
peut etre exprimee sous la forme d*un point 3D, dont les coordonnees 
10 correspondent $l la position de l'cbservateur par rapport au centre de la scene. La 
direction d'observation peut quant a elle etre exprimee sous la foime d*un vecteur 
3D. 

Avantageusement, ladite liste est geree par ledit serveur ou par un element 
intermediaire dudit reseau. 

15 Par exemple, la liste peut etre ger6e par un serveur proxy, intermediaire 

entre le serveur et le client. Le serveur peut alors emettre des requetes a 
destination du proxy, pour connaitre l'etat du contenu du cache du client Cette 
solution, bien que moins performante en ce qu'elle genere davantage d'echanges 
d ! informations, peut etre interessante dans le cas ou le serveur et le proxy sont 

20 relies par un reseau de grande perfoimance, et ou Ton souhaite "decharger" le 
serveur (par exemple si le serveur est de capacite reduite). 

Selon une caracteristique preferentielle de Tinvention, un tel procede 
comprend une phase preliminaire ({'initialisation mettant en oeuvre, pour chacun 
desdits terminaux clients, une premiere etape de transmission vers ledit serveur 

25 d'informations de visualisation initiales, et une etape de memorisation, par ledit 
serveur, dans ledit contexte coirespondant, desdites informations de visualisation 
initiales. 

Avantageusement, ladite phase prtliminaire ^initialisation comprend en 
outre une deuxi&ne etape de transmission par ledit serveur audit terminal client 
30 d ! une version grossiere de la scene a reproduire par ledit terminal client 
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Selon finvention, et contrairement aux solutions de Fart anterieur, on ne 
transmet done pas, a l'initialisation, I'integralie de la base de donnees contenant 
les objets que le client souhaite visualiser, ce qui constitue une 6conomie 
considerable, en termes de memoire pour le client et en termes de bande passante 
du reseau, a 1'initialisatioiL En effet, considerons une base de donnees de 
100 Mbits environ, et considerons que le client et le serveur sont relies par un 
reseau de type ADSL (en anglais "Asymmetric Digital Subscriber Line" pour 
"liaison numerique a debit asymarique 11 ) presentant un debit maximum de 
500kbits/s. La transmission de l r integralit6 de la base a 1'initialisation de la 
connexion entre le client et le serveur, permettant de charger toute la scene a 
visualiser chez le client, se fait done en un temps minimum de 200 s. L'invention, 
permettant de supprimer cette transmission a I'mitialisation, est done 
particulierement avantageuse pour le client puisqu'elle lui permet de visualiser une 
representation au moins grossiere de la scene de manure quasi instantanee, et 
supprime done une tongue attente d'au moins 200 s, soit plus de trois minutes, 
imposee par les techniques de Tart anterieur. 

De maniere preSrentielle, chacun desdits terminaux clients met en ceuvre 
une etape de transfert d'au moins certaines desdites informations de visualisation 
vers ledit serveur a htervalles de temps predetermines et/ou lorsque lesdites 
informations de visualisation sont modifiees. 

On notera que le choix consistant a transferer les informations de 
visualisation a intervalles de temps predetemiines, £ condition qu'elles aient 6te 
modifiees depuis leur derniere transmission, permet de minimiser le nombre de 
transmissions. 

Selon un premier mode de realisation avantageux de Finvention, lesdits 
intervalles de temps predetermines sont fixes par ledit terminal client 

lis peuvent notamment etre forces par le client, en fonction par exemple de 
la frequence a laquelle il souhaite que la scene a visualiser soit rafialchie. 
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Selon un deuxieme mode de realisation avantageux de Tinvention, lesdits 
intervalles de temps predetermines sont fonction d'au moins une caracteristique 
dudit reseau de communication. 

Notamment, ces intervalles de temps peuvent dependre de la charge du 
5 reseau, de son debit ou de son temps de latence par exemple. 

De maniere preftrentielle, a Tissue de ladite etape de transfert par ledit 
terminal client, ledit precede met en oeuvre une etape de mise a jour desdites 
informations de visualisation au sein dudit contexte correspondant 

Avantageusement, a Tissue de ladite 6tape de mise a jour, ledit serveur met 
10 en ceuvre les etapessuivantes : 

une 6tape de determination, en fonction d ! au moins certaines desdites 

infonnations de visualisation mises a jour, d'au moins un objet d'identifiant 

0 necessaire audit terminal client, et dYin niveau de restitution Lo 

correspondant ; 

15 une etape d'analyse de ladite liste representative de ladite memoire cache 

associee audit terminal client, de fe^on a identifier les eventuels couples 
<0, Io>, correspondant audit ou auxdits objets d'identifiant O et de niveau 
de restitution Lo necessaires audit terminal client, non memorises dans 
ladite liste; 

20 - une etape demission vers ledit terminal client dudit ou desdits Eventuels 
objets d'identifiant 0 et de niveau de restitution Lo, necessaires audit 
terminal client, correspondant audit ou auxdits eventuels couples <0, Lo> 
non memorises dans ladite liste ; 

une etape d'actualisation de ladite liste representative de ladite memoire 
25 cache associee audit terminal client, ajoutant, dans ladite liste, ledit ou 

lesdits couples <0, Lo> correspondant audit ou auxdits eventuels objets 
6mis. 

L'etape de determination d\in ou plusieurs objet(s) n£cessaire(s) au client 
peut resulter d*un calcul effectue par le serveur, en fonction des informations 
30 memorisees dans le contexte du client Un tel calcul peut egalement etre effectue 
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par une entite de calcul independante mais associ6e au serveur, par exemple 
prealablement a la connexion du client; l'etape de determination consiste alors, 
pour Ie serveur, a consulter Ies resultats de ce calcul de fa?on k identifier, en 
fonction des informations de visualisation associees au client, le ou les objet(s) 
5 qui lui sont necessaires. L'invention permet done, par rapport aux techniques de 
Tart anterieur, de deporter le calcul des objets n6cessaires au client, du terminal du 
client vers le serveur, ou vers l'entite de calcul qui lui est associee. 

De maniere avantageuse, ledit serveur met egalement en ceuvre: 
une etape de determination d ! au moins un objet d'identifiant 0 et de niveau 
10 de restitution Lo qui pourrait etre necessaire audit terminal client, selon au 

moins un critere de probabilite predetermine ; 

une etape d'envoi par anticipation audit terminal client, dudit au moins un 
objet d'identifiant 0 et de niveau de restitution 

Le serveur evalue par exemple la probabilite que Tobservateur se 
15 rapproche d"un objet de la scene, en fonction de revolution de ses deplacements 
anterieurs, et, si cette probability est supfrieure a un seuil predetermine, le serveur 
prend Tinitiative d'envoyer au client un objet qui lui sera necessaire dans un avenir 
proche s'il continue effectivement a se deplacer dans la meme direction 

Preferentiellement, sur reception rfau moins un objet emis par ledit 
20 serveur, ledit terminal client met en ceuvre les etapes suivantes: 

si Ie taux de remplissage de ladite memoire cache associee audit terminal 

client est inferieur k un seuil predetermine, une &ape de stockage dudit 

objet re?u dans ladite memoire cache ; 

sinon, une etape devaluation d*un critere de pertinence dudit objet re$u : 
25 • Si ftm au moins desdits objets stock6s dans ladite memoire cache 

presente un critere de pertinence de valeur inferieure a celle dudit 
critere de pertinence dudit objet re$u, ledit terminal client met en 
ceuvre une sousetape de suppression dudit objet moins pertinent de 
ladite memoire cache et une sous-etape de stockage dudit objet re$u 
30 dans ladite memoire cache ; 
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• Sinon, ledit terminal client met en oeuvre une sousetape de rejet dudit 
objet re$u. 

Un tel critere de pertinence peut par exemple dependre de la distance de 
l'objet a l'observateur. 

5 Selon une caracteristique avantageuse de invention, a Tissue de ladite 

sous-etape de suppression et/ou de ladite sous-etape de rejet, ledit terminal client 
envoie, vers ledit serveur, au moins une information d'actualisation de ladite 
memoire cache associee audit terminal client, de fapon que ledit serveur supprime 
de ladite liste representative de ladite memoire cache au moins un couple <0, I$> 
10 correspondant audit objet supprim6 au cours de ladite sous-etape de suppression 
et/ou a un objet, 6mis par ledit serveur au cours de ladite etape Remission, mais 
non memorise dans ladite memoire cache. 

De maniere preferentielle, au moins certains desdits objets comprennent au 
moins un index, de fafon k pouvoir transmettre selectivement une portion dudit 
1 5 objet a partir dudit index associe, 

Notamment, ces objets sont par exemple de Fun des types suivants : 
les images 2D ; 
les maillages ; 
les textures ; 
20 - les sons ; 

les modeles geometriques ; 
les scenes 3D ; 
les donnees video ; 
les donnees paginees. 

25 D apparaitra de maniere evidente que cette liste n'est pas exhaustive, et est 

donnee a simple titre (Texemple illustratif. 

L'invention conceme aussi un systeme de transmission de donnees, 
appelees objets, via au moins un reseau de communication, entre un serveur et au 
moins un terminal client, au moins une m6moire cache, destinee k stocker au 
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moins certains desdits objets transmis par ledit serveur, etant associee, au sein 
dudit reseau, k Tun au moins desdits terminaux clients. 

Selon l'invention, un tel systeme comprend des moyens de gestion, en 
amont desdits terminaux clients, d'au moins une liste d'objets presents dans ladite 

5 memoire cache associee a ftm desdits terminaux clients, afin de limiter les 
echanges d'infoimations relatives au contenu de ladite memoire cache entre ledit 
terminal client et ledit serveur. 

L'invention concerne egalement un serveur de donnees, appelees objets, 
connecte, via au moins un reseau de communication, a au moins un terminal 

10 client, au moins une memoire cache, destinee a stocker au moins certains desdits 
objets transmis par ledit serveur, etant associee, au sein dudit reseau, a Pun au 
moins desdits terminaux clients. Un tel serveur comprend des moyens de gestion 
d'au moins une liste d'objets presents (fans ladite memoire cache associee a Fun au 
moins desdits terminaux clients, afin de limiter les echanges ^informations 

1 5 relatives au contenu de ladite memoire cache avec ledit terminal client associe. 

L'invention conceme encore un terminal client d 1 un serveur de donnees tel 
que decrit precedemment, comprenant des moyens de transmission vers ledit 
serveur d'au moins une information d'actualisation, de fa?on k permettre audit 
serveur de mettre k jour ladite liste representative de ladite memoire cache 

20 associee audit terminal. 

D'autres caracteristiques et avantages de Tinvention apparaitront plus 
clairement a la lecture de la description suivante d'un mode de realisation 
preferentiel, donne a litre de simple exemple illustratif et non limitatif, et des 
dessins annexes, parmi lesquels : 

25 - la figure 1 presente un synoptique d'une architecture client- serveur adaptee 
a la mise en ceuvre de rinventioij 

la figure 2 illustre rarchitecture de la figure 1, completee selon l'invention 
par ajout, au niveau du serveur, d'un bloc de gestion de liste d'objets ; 
la figure 3 illustre un exemple de dialogue client - serveur mis en ceuvre 
30 selon l'invention ; 
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les figures 4A a 4C presentent un exemple de mode de realisation de 
Tinvention dans le cadre de modeles 3D codes par ondelettes 
geometriques ; 

la figure 5 illustre un deuxieme exemple de mode de realisation de 
5 Tinvention pour des objets utilisant des niveaux de detail non progressifs ; 

la figure 6 est un schema synoptique des differentes etapes mises en ceuvre 

par le serveur de Tinvention lors d*une phase de visualisation ; 

la figure 7 decrit les differentes etapes mises en ceuvre selon Tinvention 

lors d*une phase ^initialisation ; 
10 - la figure 8 presente un schema synoptique des differentes etapes mises en 

oeuvre selon Turention lors de la reception d r un objet par le terminal 

client 

Le principe general de Tinvention repose sur la gestion, en amont d'un 
terminal client, d*une liste d'objets presents dans la memoire cache associee k ce 
15 terminal, de fa?on a rfiduire les ectanges d'informations entre un serveur, auquel 
le terminal client adresse des requetes d'objets, et le terminal client lui-meme. 

On s'attache dans la suite du document a decrire une application 
particuliere de Tinvention a la transmission progressive de donnees, a travers un 
reseau de communication, pour une visualisation en temps reel d'une scene par le 
20 client (On rappelle que la presente, invention ne se limite pas a la visualisation 
d'objets, mais peut aussi s'appliquer a Taudition d'objets sonores, efc.) 

On presente, en relation avec la figure 1, un exemple d'architecture reseau 
pouvant etre mise en ceuvre dans le cadre de lHnvention. 

Une telle architecture reseau est une architecture client- serveur. Un cache 
25 1 est associe au client 2: ce cache 1 lui permet de stocker des donnees transmises 
par un serveur 3 au travers du reseau de communication 4. 

Les donnees stockees dans le cache 1 peuvent etre des donnees "presentes" 
(c r est-a-dire en cours d'utilisation par le terminal du client 2), "futures" (c ? est-a- 
dire prevues pour une utilisation ulterieure) ou "passees" (c'est-a-dire utilisees 
30 precedemment mais d&ormais au moins momentanement obsoletes). 
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Le cache 1 pent etre integre au terminal client 2, ou etre simplement 
assocte au terminal client 2, tout en etant situe en un autre point du reseau : par 
exemple, le cache 1 peut etre integre a un serveur intermediate entre le serveur 3 
et le client 2, non illustre sur la figure 1, notamment a un serveur de type proxy. 

5 Dans une variante de realisation de 1'invention, le cache 1 peut etre partagS par 
plusieurs clients 2. Par souci de simplification, on se limitera, dans la suite du 
document, a decrire le mode de realisation particulier de rinvention dans lequel le 
cache 1 est integre au terminal du client 2. 

Le terminal client 2 gere un ensemble ^informations essentielles k la 

10 selection des objets a afficher sur son ecran, en fonction de leur visibilite, telles 
que la position du client dans la scene a visualiser, l'orientation de son 
observation, et des paramfctres de selection des objets a afficher ou a reproduire, 
comme le seuil de selection des objets, un angle de vue, etc. 

Le serveur 3 gere une base de donnees 5, dans laquelle sont regroupes un 

15 ensemble d'objets que le client 2 peut souhaiter visualiser. Ces objets sont de 
preference references, au sein de la base de donnees 5, par un identifiant unique, 
reconnaissable aussi bien par le serveur 3 que par le client 2. Ces objets sont par 
exemple des maillages 3D, de preference a transmission progressive, des sons ou 
tout autre type de donnees brutes. La base de donnees 5 peut aussi contenir une 

20 pluralite d'objets de nature differente, necessaires a la reproduction d'une scene 
par le terminal client 2: par exemple, dans le cas ou le client 2 souhaite visualiser 
un concert de musique classique, la base de donnees 5 peut contenir des objets 3D 
pour reproduire graphiquement la scene, et des sons 3D pour reproduire les sons 
produits par les instruments de musique. 

25 Selon un mode de realisation prefere de rinvention, et ainsi qu'illustre en 

figure 2, le serveur 3 g£re en outre une liste 6, qui fait reference au cache 1 du 
client 2. Selon une variante de rinvention, la liste 6 n'est pas geree au niveau du 
serveur 3, mais en amont du terminal client 2, par exemple au sein d'un serveur 
proxy non illustre sur la figure 2, intermediaire entre le client 2 et le serveur 3. Par 

30 souci de simplification, on se limitera, dans la suite du document, a decrire le 
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mode de realisation particulier de l'invention dans lequel la liste 6 est geree par le 
serveur 3, mais rHomme du M6tier deduira aisement de cette description la 
realisation de l'invention dans le cas ou la liste 6 est geree en dehors du serveur 3, 
en amont du terminal client 2, 

5 La liste 6 est composee d\in ensemble de couples <0, Lo>, ou 0 est 

Pidentifiant d*un objet, et Lo correspond a un niveau de restitution de l'objet 
consider^, qui a ete transfers au terminal client 2. Comme illustre dans la suite du 
document en relation avec les figures 4 et 5, Lo peut prendre plusieurs formes 
distinctes, selon le type tfobjet 0 utilise. 

10 Le serveur 3 peut en outre gdrer un ensemble ^informations relatives au 

terminal client et/ou au client 2, en association avec la liste 6, au sein d'un 
contexte client non illustre sur la figure 2. Ces informations sont par exemple la 
position du client dans la base associee a la scfaie a visualiser, l'orientation de 
Tobservation du client, et les parametres de selection des objets a visualiser (a 

1 5 savoir notamment un seuil de selection et un angle de vue des objets de la scene). 

^architecture presentee en figure 2 permet, dans le cadre de l'invention, de 
transferer une partie des calculs de selection des donnees & visualiser du terminal 
client 2 vers le serveur 3, ce qui permet avantageusement de redirire les echanges 
entre le client 2 et le serveur 3. Cet aspect de l'invention sera decrit plus en details 

20 dans la suite du document en relation avec la figure 3. 

Dans le cadre de l'architecture de la figure 2, on decrit, en relation avec la 
figure 7, les differentes etapes mises en ceuvre Iors d'une phase ^initialisation du 
dialogue entre le serveur 3 et le client 2. Ainsi, a la connexion du client 2 au 
serveur 3, certaines donnees sont transmises afin d'initialiser le serveur 3. 

25 Au cours d r une etape referencee 71, le terminal client 2 transmet au 

serveur 3 des informations de visualisation initiates, telles que par exemple la 
position du client dans la scene a visualiser, son orientation, Tangle de vue ou 
encore le seuil de selection des objets (en fonction notamment du niveau de detail 
que souhaite obtenir le client 2). On notera que le type du seuil de selection peut 
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varier en fonction du type d'objet considere, ainsi qu'illustre dans la suite du 
document 

Au cours d'une etape de memorisation 72, le serveur 3 stocke les 
informations de visualisation initiates revues, dans le contexte associe au terminal 
5 client 2. 

Le serveur 3 peut alors transmettre (73) au terminal client 2 une version 
grossiere de la scene a reproduire, aussi appelee cartographie. Une tele 
cartographie correspond a une version elementaire de la base de donnees 5, et 
permet au client 2 d'afficher, au moins grossierement, la scene a visualiser sur son 
1 0 terminal, des le debut de la connexion. 

Sur reception de cette cartographie, le client 2 peut notamment crder, au 
sein du cache 1, differents sous-caches necessaires au stockage des donnees 
revues du serveur 3. 

Selon Invention, on choisit de stocker dans un meme sous-cache tous les 
15 objets de meme type re?us du serveur 3. Dans le cas ou tous les objets de la scene 
k visualiser sont de meme nature, il n'est pas necessaire de creer de sous-caches au 
sein du cache 1. Dans Fexemple particulier ou le client 2 visualise sur son terminal 
un relief de terrain, on cr6era de prtf&ence, au sein du cache 1, un premier sous- 
cache pour stocker les donnees relatives a la geometrie du terrain, et un second 
20 sous-cache destine a stocker la texture du terrain. 

A Tissue d'une telle phase d'initialisation, le client 2 et le serveur 3 peuvent 
transmettre et recevoir les donnees de la base 5 permettant la visualisation par le 
client 2 de la scene consideree. 

On decrit desormais, en relation avec les figures 3 et 6, le dialogue client- 
25 serveur au cours de la phase de visualisation de la scene k reproduire par le 
tenninal client 2. 

Le principe general d'une telle phase de visualisation repose sur la 
transmission, par le client 2, au serveur 3, d'informations que le serveur 3 stocke 
dans le contexte associ6 au client 2, et utilise pour transmettre au client 2 les 
30 donnees ou objets necessaires a la poursuite de la visualisation de la scene. 
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Ces informations sont de differentes natures, et sont notamment modifiees 
a differentes frequences par le client 2. Ainsi, les informations relatives a la 
position du client dans la scene k reproduire, et k sa direction d'observation sont 
modifiees tout au long de la visualisation de la scene, puisque le client 2, ou plus 
5 exactement l'observateur virtuel qui lui est associe, se deplace dans la scene et la 
parcourt du regard. 

La transmission de ces informations du client 2 au serveur 3 est 
symbolisee par la fleche (a) en trait plein de la figure 3. Elle s'effectue a une 
frequence qui peut etre definie par le client 2 (par exemple, toutes les 5 secondes), 

10 ou d&erminee en fonction des capacites du reseau 4 et du terminal client 2 (par 
exemple, la frequence de transmission des informations de visualisation peut etre 
fixee a 2 secondes pour un r6seau haut debit, et a 6 secondes pour un reseau bas 
debit). La transmission de ces informations (a) est en outre avantageusement 
conditionnee par un critere evenementiel, afin de limiter le nombre d'echanges (a) 

15 entre le client 2 et le serveur 3 : ainsi, la transmission (a) des informations de 
position et de direction d'observation n'a lieu que si elles ont ete modifiees depuis 
leur derniere transmission (a) au serveur 3. 

Par exemple, si le client 2 s'est deplace dans la scene depuis la derniere 
transmission (a) d'informations de position et de direction d'observation au 

20 serveur 3, une nouvelle transmission (a) d'informations modifiees aura lieu 5 
secondes plus tard (si la frequence de transmission a ete fixee a 5 secondes). 

Selon l'invention, le client 2 n'attend pas de reponse de la part du serveur 3 
a la transmission (a), qui peut done se faire en rn>de non connecte (de type UDP 
par exemple, pour "User Datagram Protocol"). 

25 Ainsi qu'illustre en figure 6, sur reception 61 des informations de position 

et d'orientation transmises (a) par le client 2, le serveur 3 effectue une mise a jour 
62 du contexte associe au client 2, en y memorisant les nouvelles informations de 
position et d'orientation revues. 

D'autres informations, comme les parametres de selection des objets a 

30 transmettre, ou une information d'actualisatdon du cache 1, sont preferentiellement 



2834104 



transmises selon un critere evenementiel, a savoir leur modification. Une telle 
. transmission du client 2 au serveur 3 est symbolisee par la fleehe (b) en traits 
pointilles sur la figure 3. Sur r&eption, le serveur 3 stocke ces informations, soit 
dans la liste 6 (pour reformation d'actualisation du cache), soit plus generalement 
5 dans le contexte assocte au client 2. 

Ainsi, rinformation dactualisation du cache 1 du client 2 est transmise au 
serveur 3, sous la forme d*une liste de couples <0, Ie> correspondant aux objets 
presents dans le cache 1 (ou dans Tun des sous-caches du cache 1), a chaque fois 
que : 

10 - un ou plusieurs objet(s) ont 6t£ supprimes du cache 1 par le 

terminal client 2 pour permettre de stocker de nouveaux objets transmis 
par le serveur 3 ; ou 

lorsqu'un ou plusieurs) objet(s) transmis par le serveur 3 ont ete 
rejetes par le terminal client 2. 
15 Ces aspects seront decrits plus en details par la suite en relation avec la 

figure 8, qui illustre le traitement effects par le terminal client 2 sur reception 
d'objets transmis par le serveur 3. 

O represente un identifiant d*un objet de la scfcne, et 1$ est une information 
relative au niveau de detail de restitution de l'objet 0. La structure de Io depend 
20 bien sur du type d'objet 0, et de la methode utilisee pour coder les niveaux de 
detail associes. Ainsi, Lo peut etre une valeur representative du niveau de detail 
(par exemple dans le cas ou l'invention met en oeuvre une technique de type 
HLOD pour 'Tfierarchical Level Of Detail", en fran^ais, "niveau de detail 
hierarchique ,f ), ou un ensemble de valeurs representatives codant les raflfinements 
25 g6ometriques de Tobjet 0, ainsi qu f illustre par la suite en relation avec les figures 
4et 5. 

De meme, les parametres de selection des objets (tels que le seuil de 
selection des objets, Tangle de vue, ou toute autre information permettant la 
modification de la selection des objets) seront transmis lors de la modification de 
30 leur valeur. On peut en efFet envisager qu'en cours de visualisation, le client 2 
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decide de modifier le seuil de selection defini lors de la phase ^initialisation, de 
fa^on par exemple a le diminuer, pour pouvoir obtenir une reproduction plus 
detaillee de la scene. 

On rappelle qu'un tel seuil de selection peut etre defini de nombreuses 
5 manieres, et notairanent etre evalue en degres, en pixels projetes, en taille, etc. 
Ainsi, le serveur 3 peut ne transmettre au client 2 que les objets qui, apres 
projection sur Fecran du terminal client 2, seront vus par Tobservateur virtuel sous 
un angle superieur ou egal a 1°. Dans le cas d*un objet associe a un maillage code 
par ondelettes, le seuil de selection peut etre par exemple fixe de fa^on a ne 
... 10 selectionner que les coefficients d'ondelettes induisant une deformation du 
maillage sup&ieure ou egale a 2°. Si Tobjet considers est un son, le seuil de 
selection peut dependre de la frequence de ce son, ou de sa duree. Le seuil de 
selection, ainsi que tous les autres parametres de selection peuvent encore etre 
definis de toute autre maniere permettant au serveur 3 de selectionner les objets 
1 5 pertinents a transmettre au client 2. 

En fonction des informations contenues dans le contexte associ6 au client 

2 (information de position, de direction d'obseravtion, parametres de selection, 
information relative au contenu du cache 1), le serveur 3 transmet au client 2 les 
objets ou donnees qui sont visiblement pertinents. Cette transmission est 

20 symbolisee par la fleche (c) grisee continue sur la figure 3. La determination des 
objets visuellement pertinents peut resulter de calculs effectues par le serveur 3, 
ou par une autre entite du riseau 4. Elle peut egalement avoir ete calculee 
prealablement a Tetablissement de la connexion entre le serveur 3 et le client 2, et 
mdmorisee au sein du reseau, par exemple dans le serveur 3. 

25 Ainsi, dans le mode de realisation particulier illustre en figure 6, le serveur 

3 determine (63), en fonction de toutes ou partie des informations de visualisation 
(par exemple en fonction de rinformation de position, de direction d'observation 
du client 2 et des parametres de selection) contenues dans le contexte du client 2, 
le ou les objets O n&essaires au terminal client 2, a un niveau de restitution 

30 adequat. 
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Le serveur 3 analyse alors (64) la liste 6 associee au cache 1 du terminal 
client 2, mise a jour en fonction des demieres informations d'actualisation revues, 
pour determiner si le ou les objet(s) necessaire(s) au client 2, dans le niveau de 
iafBnement lo adequat, sont deja memorises dans le cache 1 du client 2. 
5 Dans le cas contraire, le serveur 3 emet (65) ce ou ces objet(s) vers le 

terminal client 2. 

Selon l'invention, on peut egalement mettre en ceuvre une methode 
^anticipation permettant su serveur 3 de transmettre (c) au client 2 des objets qui 
ne lui sont pas encore n6cessaires, mais dont le serveur prevoit qu'ils le 

10 deviendront dans un futur proche. Par exemple, si le serveur 3 determine que le 

client 2 s'est deplace a plusieurs reprises successives dans la meme direction, il 
peut transmettre (c) au client 2 un objet qui n'est pas encore pertinent pour le 
client 2, mais qui entrera prochainement dans son champ de vision si le client 2 
continue a se deplacer dans cette direction. 

15 Lors de cette transmission (c), le serveur 3 modifie la liste 6 associee au 

client 2, en y ajoutant, sous forme de couples <0, Io>, les donnees transmises (c) 
au client 2, en considerant que toutes les donnees transmises au client ont ete 
stockees dans le cache 1. Cette etape d'actualisation est illustree en figure 6 par 
l'etape referencee 66. Une telle modification de la liste 6 permet avantageusement 

20 de minimiser les redondances de transmission. II peut acriver que certaines des 
donnees transmises (c) par le serveur 3 au client 2 ne soient pas stock6es dans le 
cache 1, en cas par exemple d'erreur de transmission liee au reseau, ce qui entraine 
une perte de coherence entre 1'etat du cache 1 et la liste 6. ^invention prevoit 
avantageusement de remedier k ce probleme. Le maintien de la coherence entre 

25 F6tat du cache 1 et la liste 6 sera decrite plus en details par la suite en relation avec 
la figure 8. 

On decrit desormais, en relation avec les figures 4A a 4C, un exemple de 
visualisation par le client 2 de modeles tridimensionnels codes par ondelettes 
geometriques. On rappelle que les methodes de codage dites "a ordelettes" 
30 perrnettent de representer un maillage comme une succession de details ajoutfe a 
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un maillage de base. La theorie generate de cette technique est notamment decrite 
dans l'article de M. Lounsbery, T. DeRose et J. Warren, "Multiresolution Analysis 
for Surfaces of Arbitrary Topological Type" (ACM Transaction on Graphics, Vol 
16, No.l, pp. 34-73, Janvier 1997). 
5 Comme decrit prec&lemment, a Tissue de la phase ^initialisation du 

dialogue client- serveur, Ie serveur 3 transmet au terminal client 2 une version 
grossiere, appelee cartographie, de la base 5. Dans le cas d*une base 5 constitute 
d*un ensemble de modeles 3D (illustre en figures 4A a 4Q, cette cartographie 
correspond par exemple a un ensemble de valeurs indiquant au terminal client 2 

10 Templacement et la taille des differents objets de la base 5, par exemple sous la 
forme de replacement et de la taille de boites 41 A et 42A englobant ces objets. 

En fonction de la visibilite de ces objets (c'est-a-dire en fonction de leur 
presence partielle ou totale dans le champ de vision de Tobservateur, de leur 
distance a Fobservateur, etc.), Ie serveur 3 transmet ensuite le maillage de base 

15 41B, 42B de ces objets au client 2. Ces maillages de base 41B, 42B permettent au 
client 2 de construire les differents sous-caches qui lui sont necessaires pour 
stocker les donnees en provenance du serveur 3, et d'elaborer une liste de couples 
<0, Lo> initiale correspondante. 

Dans l'exemple des figures 4A a 4C, on considere que les maillages de 

20 base 41B, 42B comprennent chacun n faces. La liste 6 gerfe par le serveur 3 pour 
le client 2 sera done constitute d'un ensemble de couples <0, <N1, Nn», ou 
O repr&ente 1'identifiant de l'objet et oil Ni repr6sente le nombre de coefficients 
d'ondelettes presents dans le cache 1 pur la face i du maillage de base 4 IB, 42B. 
Lors de la transmission du maillage de base 4 IB, 42B, les Ni pour ie[l,n] sont 

25 tous initialises a zero. 

On notera que la connaissance des Ni pour ie[l,n] suffit au serveur 3 pour 
determiner de fagon exacte les coefficients d'ondelettes presents dans le cache 1 
du client 2, a condition quhin ordre de tri des coefficients tfondelettes pour 
chacune des faces soit pr£alablement determine. Ainsi, si le client 2 informe le 

30 serveur 3, au cours de l'&ape (b) de la figure 3, qu ! il dispose de 30 coefficients 
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pour la face n°8 du maillage 41B, le serveur 3 commencera a transmettre les 
coefficients, qui sont associes k la face n°8 du maillage 41B, et pertinents pour le 
client 2, a partir du 31*™ coefficient On rappelle que la selection des coefficients 
pertinents tient compte des informations de visualisation memorisees dans le 

5 contexte du client, telles que rinfoimation de position, d'orientation d'observation, 
et les parametres de selection. 

L'ordre de tri des coefficients par face du maillage est pr&erentiellement 
conserve a leur arrivee dans le terminal du client 2. 

A partir des coefficients transmis par le serveur pour chacune des faces 

10 visibles du maillage de base 41B, 41C, le terminal client 2 peut reconstruire une 
representation detaillee 41 C, 42C des objets de la scene. 

On presente desoimais en relation avec la figure 5, un deuxieme exemple 
de mise en oeuvre de l'invention, pour des objets utilisant des niveaux de detail 
non prognessifs. Contrairement a l'exemple precedent mettant en oeuvre une 

15 technique de codage par ondelettes, dans lequel les objets, ou des portions 
d'objets, peuvent etre raffines selectivement en fonction du point de vue de 
l\itilisateur, on presente ici le cas d*un objet represents par quatre niveaux de 
detail successifs references 51 a 54. 

Comme dans l'exemple des figures 4A a 4C, le serveur 3 commence par 

20 transmettre au client 2 une cartographie de la base de donnees 5, qui permettra au 
client 2 de connaitre les donntes a afficher. Pour chaque <bjet de la base 5 qu'il 
estime potentiellement visible, le serveur 3 transmet ensuite l'objet dans son 
niveau de detail le plus bas 54 (c'est-a-dire la version la plus grossiere de l'objet) 
au client 2. Au cours de la visualisation, le serveur 3 transmettra ensuite les 

25 niveaux de detail superieurs 53 a 51, en fonction de la position du client 2 dans la 
scene. Ainsi, si le client 2 s'approche progressivement de l'objet de la figure 5, le 
serveur 3 transmettra progressivement les niveaux de detail 53, puis 52, puis 51, 
en fonction de la distance de Pobservateur a l'objet 

Le codage du niveau de raffinement Lo associS a l'objet 0 dependra des 

30 contraintes imposees par Implication mise en oeuvre, notamment du caractere 



2834104 



obligatoire ou non de la transmission des objets dans l'ordre des niveaux de detail 
associes. 

Ainsi, dans le cas ou le serveur 3 est oblige de transmettre les objets au 
client 2 dans l'ordre de leur niveau de raffinement, on choisira de donner a lb la 
5 valeur du niveau de detail le plus elev6 present dans le cache 1 pour Fobjet 0. Si 
le cache 1 contient les niveaux de raffinement references 54 (niveau de 
raffinement 0) et 53 (niveau de raffinement 1) pour Fobjet 0, le prendra la valeur 
"1". La liste 6 contiendra alors le couple <0, n l">, et le serveur 3 en deduira que 
le cache 1 contient les niveaux de raffinement 0 et 1 pour Fobjet 0. D ne 
10 transmettra done au client 2, si necessaire, que le niveau de detail directement 
superieur, a savoir le niveau reference 52 correspondant a un niveau de 
raffinement "2". 

Dans le cas ou la transmission du serveur 3 au client 2 dans l'ordre des 
niveaux de raffinement n'est pas obligatoire, Lo representee pour Fobjet 0 

15 Fensemble des niveaux de raffinement memorises pour cet objet dans le cache 1 
du client. On choisira par exemple de coder le sur plusieurs bits, de &9on que le 
bit, dont la position dans Lo correspond a un niveau de detail memorise dans le 
cache 1 du client 2, prenne la valeur 1. Dans Fexemple de la figure 5, si le cache 1 
du client 2 contient les niveaux de raffinement "0" et "2", correspondant 

20 respectivement aux representations referencees 54 et 52, on aura Lo = 0101. Le 
serveur 3 saura alors qu'il peut transmettre les niveaux de detail 1 et 3, 
correspondant respectivement aux representations referencees 53 et 51, selon 
Femplacement de Futilisateur dans la scene (notamment selon sa distance a Fobjet 
consid6re, et sa direction d f observation). 

25 De meme, si Fon considers un objet auquel sont associes huit niveaux de 

detail successifs, et si le cache 1 du client 2 comprend pour cet objet les niveaux 
de detail 1, 2, 4 et 7, le aura la valeur "01001011". Le serveur 3 sait alors qu'il 
peut transmettre les niveaux 3, 5, 6 et 8 au client 2, selon les informations de 
visualisation memorisees dans le contexte associ6. 
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On notera que ce type de codage de h n'est pas restraint aux objets 3D 
composes de faces, mais peut etre applique a tout type de donn6es composees de 
niveaux de detail non progresses, comme des textures multi-resolutions par 
exemple. 

5 On presente desormais brievement un troisieme exemple ^application de 

Tinvention au cas des donnees brutes de type son ou video, ou encore au cas des 
donntes paginees (de type gestion de stock, de personnel, etc.). 

Dans le cas de donn&s brutes de type son par exemple, la transmission 
d'une cartographie par le serveur 3 peut ne pas exister. Elle peut aussi 

10 correspondre a la transmission par le serveur 3 d'un ensemble de donnees 
temporelles, indiquant par exemple au client 2 qu*un son de violon devra Stre joue 
ou reproduit dans 30 secondes. Pour ce type d'objets sonores, l'information de 
restitution Lo correspondra par exemple au pourcentage de donnees transmis. La 
valeur de Lo permettra ainsi au serveur 3 de savoir par exemple que les 15 

15 premieres secondes d'un son d'une duree de 2 min 30s sont stockees dans le cache 
1 du client 2. 

Dans le cas de donnees paginees, la cartographie emise a Tinitialisation par 
le serveur 3 pourra par exemple correspondre au nombre total de pages existant 
pour chacune des donnees <hns la base de donnees 5. L'information de restitution 
20 Lo pourra dans ce cas etre une donnSe variable de la forme <N, NO, . . Nn>, ou N 
represente le nombre de pages connues pour cet objet (c'est-^-dire le nombre de 
pages stockees dans le cache du client pour cet objet), et ou Ni indique le nom de 
laf mc page. 

On decrit desormais, en relation avec la figure 8, les differentes etapes 
25 mises en ceuvre par le terminal client 2, sur reception 81 d*un ou plusieurs objets 
Or envoyes par le serveur 3 au cours de la transmission referencee (c) sur la 
figure 3. Par souci de simplification, on decrit ici le cas ou le serveur 3 transmet 
un unique objet Or au client 2. La technique mise en oeuvre dans le cas ou 
plusieurs objets sont re$us par le client 2 et/ou le cache 1 s'en deduit bien sur 
30 ais&nent 



2834104 



Au cours (Tune etape referencee 82, le terminal client verifie le taux de 
remplissage du cache 1 qui ltd est associe. Dans le cas ou le cache 1 n'est pas 
integrt au terminal 2, cette verification est mise en ceuvre par l'etite chargee de la 
gestion du cache 1, par exemple un serveur proxy auquel le cache 1 est integrS. 
5 Si le taux de remplissage du cache 1 est inferieur k un seuil de remplissage 

predetermine, indiquant ainsi qu'il est encore possible de stocker un ou plusieurs 
nouveaux objets dans le cache 1, l'objet re$u Cfe est memorise (83) dans le cache 1 
du client 2. 

Dans le cas contraire, il n'est pas possible de stocker l'objet Or re$u du 
10 serveur 3 dans le cache 1, en Petal On determine alors (84) s'il existe un objet Os 
du cache 1, qui est visuellement moins pertinent que l'objet re?u Or pour 
Tobservateur. Un tel objet Os peut etre un objet qui est sorti du champ de vision 
du client 2, en raison par exemple d'un emplacement recent, ou d\in changement 
de direction d'observation du client 2. 
15 Si un tel objet moins pertinent Os existe, il est supprime (86) du cache 1, 

de fagon que le nouvel objet Q* re9U du serveur 3 puisse etre stocke dans le cache 
1 & sa place. 

Le terminal client 2 envoie alors (87) une information d'actualisation de 
l'etat du cache 1, pour informer le serveur 3 de la suppression de cet objet Cfedu 
20 cache 1 , et de la memorisation correspondante de l'objet Or. 

Si en revanche tous les objets stockes dans le cache 1 sont visuellement 
plus pertinents que l'objet Ck re$u du serveur 3, l'entite chargee de gerer le cache 1 
(le terminal client 2 par exemple) rejette cet objet Or. 

Le terminal client 2 envoie alors (87) une information d'actualisation de 
25 l'etat du cache 1, pour informer le serveur 3 que l'objet Or n'a pas pu etre 
memorise dans le cache 1. 

Cette information d'actualisation permet egalement au serveur 3 de 
maintenir la coherence entre Fetat du cache 1 et la liste 6 representative de son 
contenu. En effet, sur reception de cette information d'actualisation, le serveur 3 
30 peut notamment verifier que tous les objets qu'il a transmis au client 2, et qu'il a 
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done ajoutes a la liste 6, ont bien 6t6 re$us sans erreur par le client 2 et/ou le cache 
1. Ceci permet notamment de traquer les probtemes de transmission qui pourraient 
etre lies a une defaillance du reseau 4. 

Le serveur 3 compare done 1'information d'actualisation reqae du client 2 
et la liste 6, de maniere a verifier leur confoimite et, le cas echant, a mettre a jour 
la liste 6 en fonction de rinformation d'actualisation re9ue. 
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REVENDICATIONS 

1. Procede de transmission de donnees, appetees objets, via au moins un 
reseau de communication, entre un serveur et au moins un terminal client, 

au moins une memoire cache, destinee a stocker au moins certains desdits objets 
5 transmis par ledit serveur, etant associee, au sein dudit reseau, a Yun au moins 
desdits terminaux clients, 

caract&is£ en ce qu'on gere, en amont desdits terminaux clients, au moins une 
liste d'objets presents dans ladite memoire cache associee a l'un desdits terminaux 
clients, afin de limiter les echanges d'informations relatives au contenu de ladite 
1 0 memoire cache entre ledit terminal client et ledit serveur. 

2. Procede de transmission selon la revendication 1, caracterisS en ce qu'on 
memorise, au sein de ladite liste, un identifiant de chacun desdits objets et, pour 
Pun au moins desdits objets, une information de restitution dudit objet 

3. Procede de transmission selon la revendication 2, caracterise en ce que, 
15 pour l'un au moins desdits objets, ladite information de restitution est relative a un 

niveau de raffinement dudit objet 

4. Procede de transmission selon Fune quelconque des revendications 2 et 3, 
caracterise en ce que, pour chacun desdits objets stockes dans ladite memoire 
cache, ladite liste comprend un couple <0, Lo> comprenant ledit identifiant O 

20 dudit objet et ladite information de restitution Lo dudit objet 

5. Procede de transmission selon l'une quelconque des revendications 1 a 4, 
caracterise en ce que, pour chacun desdits terminaux clients, on associe a ladite 
liste au moins une information relative audit terminal client et/ou a un utilisateur 
dudit terminal client, appelee information de visualisation, de fa$on a former un 

25 contexte. 

6. Procede de transmission selon la revendication 5, caracteris6 en ce que 
ladite information de visualisation appartient au groupe comprenant : 

une information de position dudit utilisateur ; 
une direction d'observation dudit utilisateur ; 
30 - les parametres de selection desdits objets. 
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7. Procede de transmission selon Tune quelconque des revendications 1 a 6, 
caracterise en ce que ladite liste est g6r6e par ledit serveur ou par un element 
intermediaire dudit reseau. 

8. Procede de transmission selon Tune quelconque des revendications 5 a 7, 
5 caracterise en ce qu ! il comprend une phase preliminaire ^initialisation mettant en 

oeuvre, pour chacun desdits terminaux clients, une premiere etape de transmission 
vers ledit serveur d'informations de visualisation initiates, et une etape de 
memorisation, par ledit serveur, dans ledit contexte correspondant, desdites 
informations de visualisation initiates. 
10 9. ProcSde de transmission selon la revendication 4, caracterise en ce que 
ladite phase preliminaire ^initialisation comprend en outre une deuxieme etape de 
transmission par ledit serveur audit terminal client dune version grossiere de la 
scene a reproduire par ledit terminal client 

10. Procede de transmission selon Tune quelconque des revendications 5 a 9, 
15 caracterise en ce que chacun desdits ferminaux clients met en ceuvre une etape de 

transfert d'au moins certaines desdites informations de visualisation vers ledit 
serveur a intervalles de temps predetermines et/ou lorsque lesdites informations 
de visualisation sont modifiees. 

11. Procede de transmission selon la revendication 10, caracteris6 en ce que 
20 lesdits intervalles de temps predetermines sont fixes par ledit terminal client 

12* Procede de transmission selon la revendication 11, caracterise en ce que 
lesdits intervalles de temps predetermines sont fonction d'au moins une 
caracteristique dudit reseau de communication. 

13. Procede de transmission selon Tune quelconque des revendications 10 a 
25 12, caracterise en ce qu'a Tissue de ladite etape de transfert par ledit terminal 

client, ledit procede met en oeuvre une etape de mise a jour desdites informations 
de visualisation au sein dudit contexte correspondant 

14. Procede de transmission selon la revendication 13, caracterise en ce qu'a 
Tissue de ladite etape de mise & jour, ledit serveur met en ceuvre les etapes 

30 suivantes : 
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une etape de determination, en fonction d f au moins certaines desdites 
informations de visualisation mises a jour, d f au moins un objet d'identifiant 
0 necessaire audit terminal client, et d'un niveau de restitution Lo 
correspondant ; 

5 - une etape tfanalyse de ladite liste representative de ladite memoire cache 
associee audit terminal client, de faQon a identifier les eventuels couples 
<0, I*>, correspondant audit ou auxdits objets d'identifiant 0 et de niveau 
de restitution Lo necessaires audit terminal client, non memorises dans 
ladite liste; 

10 une etape d'&nission vers ledit terminal client dudit ou desdits eventuels 

objets d'identifiant 0 et de niveau de restitution Lo, necessaires audit 
terminal client, correspondant audit ou auxdits eventuels couples <0, Lo> 
non memorises dans ladite liste ; 

une etape d'actualisation de ladite liste representative de ladite memoire 
15 cache associee audit terminal client, ajoutant, dans ladite liste, ledit ou 

lesdits couples <0, Lo> correspondant audit ou auxdits eventuels objets 
emis. 

15. Proc6de de transmission selon la revendication 14, caracterise en ce que 
ledit serveur met egalement en ceuvre: 
20 - une 6tape de determination d'au moins un objet d'identifiant 0 et de niveau 

de restitution Lo qui pourrait etre n6cessaire audit terminal client, selon au 

moins un entire de probabilite predetermine ; 

une 6tape d'envoi par anticipation audit terminal client, dudit au moins un 
objet d'identifiant 0 et de niveau de restitution Lo. 
25 16. ProcedS de transmission selon Fune quelconque des revendications 14 et 
15, caracterise en ce que, sur reception d'au moins un objet emis par ledit serveur, 
ledit terminal client met en ceuvre les etapes suivantes: 

si le taux de remplissage de ladite memoire cache associee audit terminal 
client est inferieur a un seuil predetermine, une etape de stockage dudit 
30 objet regu dans ladite memoire cache ; 
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sinon, une etape devaluation d'un critere de pertinence dudit objet re<?u : 

• Si Fun au moins desdits objets stockes dans ladite memoire cache 
presente un critere de pertinence de valeur inferieure a celle dudit 
critere de pertinence dudit objet re$u, ledit terminal client met en 

5 ceuvre une sous etape de suppression dudit objet moins pertinent de 

ladite m&noire cache et une sous-etape de stockage dudit objet re?u 
dans ladite memoire cache ; 

• Sinon, ledit terminal client met en oeuvre une sousetape de rejet dudit 
objet re(?u. 

10 17. Proc6d6 de transmission selon la revendication 16, caract&ise en ce qu'a 
Tissue de ladite sous-etape de suppression et/ou de ladite sous-etape de rejet, ledit 
terminal client envoie, vers ledit serveur, au moins une information d'actualisation 
de ladite memoire cache associee audit terminal client, 

de fa$on que ledit serveur supprime de ladite liste representative de ladite 
15 memoire cache au moins un couple <0, Lo> correspondant audit objet supprimS 
au cours de ladite sous-etape de suppression et/ou a un objet, emis par ledit 
serveur au cours de ladite etape Remission, mais non memorise dans ladite 
memoire cache. 

18. Precede de transmission selon Tune quelconque des revendications 1 a 17, 
20 caracterise en ce que au moins certains desdits objets comprennent au moins un 

index, de fason a pouvoir transmettre selectivement une portion dudit objet a 
partir dudit index associe. 

19. Systeme de transmission de donnees, appelees objets, via au moins un 
reseau de communication, entre un serveur et au moins un terminal client, 

25 au moins une memoire cache, destinfe a stocker au moins certains desdits objets 
transmis par ledit serveur, etant associee, au sein dudit reseau, a l'un au moins 
desdits Ceiminaux clients, 

caracterise en ce qu'il comprend des moyens de gestion, en amont desdits 
terminaux clients, d'au moins une liste d'objets presents dans ladite memoire 
30 cache associee a l'un desdits terminaux clients, afin de limiter les echanges 
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^informations relatives au contenu de ladite m6moire cache entre ledit tenninal 
client et ledit serveur. 

20. Serveur de donnees, appetees objets, connecte, via au moins un r&eau de 
communication, a au moins un terminal client, 

5 au moins une memoire cache, destinee a stocker au moins certains desdits objets 
transmis par ledit serveur, etant associee, au sein dudit r6seau, a Tun au moins 
desdits terminaux clients, 

caracterise en ce quHl comprend des moyens de gestion d'au moins une liste 
d'objets presents dans ladite memoire cache associee a l\in au moins desdits 
10 terminaux clients, 

afin de limiter les ^changes d'informations relatives au contenu de ladite m&noire 
cache avec ledit tenninal client associk 

21. Terminal client d ! un serveur de donnees selon la revendication 20, 
caracterise en ce qu ! il comprend des moyens de transmission vers ledit serveur 

15 d'au moins une information d'actualisation, de fa$on a permettre audit serveur de 
mettre a jour ladite liste representative de ladite memoire cache associee audit 
terminal. 
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Figure 4A 
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Reception des informations de position et 
d'orientation transmises par le terminal client 

a intervalles de temps predetermines, a 
condition qu'elles aient 6te modifies depuis 
leur dernfere transmission. 
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Mise a jour des informations de 
position et d'orientation, dans le 
contexte client. 
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Determination en fonction d'au moins certaines 
des informations de visualisation du contexte 
client d'au moins un objet O nScessaire au 
terminal client, a un niveau de raffinement U. 



Analyse de la liste assoctee au cache du 
terminal client pour determiner si le ou les 
objet(s) n6cessaire(s), associ6(s) au niveau de 
raffinement U sont memorises dans le cache. 
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Emission vers le terminal client du ou des objets 

0 necessaire(s), associe(s) au niveau de 
raffinement L 0 , non memorises) dans le cache, 
s'il(s) existe(nt). 
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Actualisation de la liste associ£e au cache 
du terminal client, par ajout, sous forme de 
couples (0, U) du ou des objets 6mis vers 
le terminal client. 
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Figure 6 
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Transmission du terminal client au 
serveur conformations de visualisation 

initiates : information de position, 
direction d'observation, parametres de 
selection, ... 



Memorisation par le 
serveur des informations 
de visualisation initiates 
dans le contexte associe 
au terminal client. 
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Transmission du serveur au terminal 
client d'une version grosstere de la sc6ne 
& reproduire (cartographie) 
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Figure 7 



2834104 

6/6 



Reception par le terminal d'un objet 

d'identifiant 0 et de niveau de 
raffinement U £mis par le serveur. 
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